We received a report from @ritzdorf and @antonper about a potential security issue for people extending our ERC777 contract.

One of the characteristics of ERC777 is that it allows reentrancy through the send and receive hooks, so the token needs to be coded carefully to avoid a reentrancy attack. In particular, the contract needs to be in a consistent state whenever an external call is made to an untrusted address. For a detailed writeup about reentrancy check out our article Reentrancy After Istanbul.

The ERC777 contract we provide is safe against reentrancy, because during send and receive hooks it is in a consistent state. However, extending this contract with a custom _beforeTokenTransfer function could allow a reentrancy attack to happen. More specifically, when burning tokens, _beforeTokenTransfer is invoked before the send hook is externally called on the sender while token balances are adjusted afterwards. At the moment of the call to the sender, which can result in reentrancy, state managed by _beforeTokenTransfer may not correspond to the actual token balances or total supply.

For example, in a hypothetical ERC777Snapshot contract with balance snapshots, a custom _beforeTokenTransfer function may keep track of an account's balance history in a new mapping. When the send hook is called on the sender, the balance snapshot history and the current token balances would be out of sync, the kind of inconsistent state that is vulnerable to reentrancy attacks.

Am I affected?

If you're using our implementation of ERC777 from version 3.3.0 or earlier, and you define a custom _beforeTokenTransfer function that writes to a storage variable, you may be vulnerable to a reentrancy attack. If you're affected and would like assistance please write to [email protected].

PR Checklist

• Tests
• Changelog entry